HA State: ensure not this and another instance can be responsible #825
Conversation
In theory, this should not happen. This assumption is based on the trust in the database transaction performing the HA realization logic. However, one debugged log let one assume that this happened anyway. This change mostly signals an error while also explicitly giving up the HA state. Doing so should at least alarm a person reading the logs.
oxzi
force-pushed
the
ha-state-both-responsible-reject
branch
from
90c366b to
a38491a
Compare
|
For the record, this behavior was seen in the linked ticket a short time after something in the database cluster went south. Furthermore, I have rebased the branch to reflect the latest changes on the main branch. |
The build in the mentioned ticket contains both this branch as well as #800. So far, I cannot think of a valid situation which will break with this change, as it addresses a previously under-specified state. |
Yes, I know. I meant that with #800 there were no (more) logs that say "Other instance is responsible...", right? So I wanted to question whether this change is actually necessary, but at the same time say that more protection can't hurt. |
Unfortunately, there was no deployment of only #800, but always of these two PRs combined. Furthermore, I never got detailed enough logs to be able to answer this question. Thus, at least in this very scenario, both branches combined seemed to solve or at least mitigate the issue. |
In theory, this should not happen. This assumption is based on the trust in the database transaction performing the HA realization logic. However, one debugged log let one assume that this happened anyway.
This change mostly signals an error while also explicitly giving up the HA state. Doing so should at least alarm a person reading the logs.
ref/IP/55850